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* A rvjrworit manager for a tciccommunicauons network has a 
client-server architecture. The software components of the network 
manager include a set of clients (50) which form pan of the 
application programs of the networt manager a 
(32) a database (36) containing details of the netwoilc and a 
cominunications stack (38) for communicating with exchanges 
managed by the network manager. The clients (50) gcneiite 
requests to run jobs on seiven (52) and (54). The jobs which are 
run on server (52) are cventuaUy destined for a resource in the form 
of a database (36). white the jobs which are nin on servers (5*) « 
evennially destined for resources in the form of exchanges. The 
requests are initially pa«ed lo softwtre module IBM. This moduk 
then checks if the resource for which the job is destined is free 
and if nou puts the job on a holding queue. If the resource is ftte, 
it checks whether the job is scheduled for immedutc execution or 
execution at a funire time. If it is scheduled for execution « a future 
time, u is put on a queue of scheduled jobs. If the job is scheduled 
for immediate execution, the module JBM checks if a server is free 
to accept the job. If no server is free, the job is puion a queue of 
jobs awaiting immediate execuuon. If the server is free, the module 
IBM instructs a module SMAN to load the job onto the free server. 
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^p^T.jprt. gv<;T PM HtVTNG rrTPMT-SCftVSR ARCHITECTURE 

This invention relates to a computer system having a 
client-server architecture and also to a method of operating 
5 a computer system having this architecture. 

A computer system having a client-server architecture 
comprises a set of software modules known as clients and a 
further set of software modules. Icnown as servers, for 
serving requests from the clients to run jobs. This type of 
10 architecture enables jobs from the clients to be distributed 
among the servers. The servers may be of similar or 
differing types. with this type of architecture, it is 
desirable to provide a mechanism for controlling the 
scheduling of requests by the clients to run jobs on the 
15 servers. 

According to one aspect of this invention there is 
provided a computer system having a client-server 
architecture, said system comprising: a set of clients; a set 
of servers for serving requests from the clients to run jobs; 
20 means for managing requests from the clients to run DObs on 
servers; and means for loading jobs on to servers; said 
request managing means being arranged to receive requests 
from the clients and. on receiving a request, to perform the 
following operations: check if a - server is free to run the 
2 5 job; if a server is not free, put the job on a queue for jobs 
each of which is ready for execution when a server becomes 
free; and when a server is free to run a job, instructing 
said job loading means to load a job on to the server. 

The provision of a queue for jobs each of which is 
30 ready for execution when a server becomes free enables the 
computer system to deal with the situation where clients are 
requesting DObs to be run on servers at a time when a server 
is not free to run the jobs. 

According to a second aspect of this invention there 
35 is provided a computer system having a client-server 
architecture, said computer system comprising: a set of 
clients; a set of servers for serving requests from the 



BNSOOCID: <VWO 9603a«Al> 



wo 96/03692 



PCT/CB95/01705 



clients to run jobs; means for managing requests from clients 
to run jobs on servers; and means for loading jobs on to 
servers; said request managing means being arranged to 
receive requests from the clients and, on receiving a request 
5 from a client to run a job which is destined for a resource 
accessed by a server, to perform the following operations; 
check is the resource is free to run the job; and if the 
resource is not free, put the job on a queue for jobs each of 
which is waiting for a resource to become free. 

10 According to a third aspect of this invention there is 

provided a method of operating a computer system having a 
client-server architecture, said computer system comprisinc 
a set of clients and a set of servers for serving requests 
from the clients to run jobs, for each request made by a 

15 client to run a job on a server, said method comprising th€ 
steps of: 

checking if a server is free to run the job; and 

if a server is not free to run the job, putting the 
job on a queue for ^obs each of which is ready for execution 
20* when a server becomes and 

when a server is free to run the job, loading a job or 
to the server. 

According to a fourth aspect of this invention there 
is provided a method of operating a computer system having a 
25 client-server architecture, said computer system having a set 
of clients and a set of servers for serving requests from the 
clients to run ^obs; for each request made by a client to rui 
a ]ob on a resource accessed by a server, said methot 
including the steps of: checking if the resource is free t< 
30 run the job; and, if the resource is not free, putting th- 
3 0b on a queue for jobs each of which is waiting for ■ 
resource to become free. 

This invention will now be described in more detail 
by way of example, with reference to the drawings in which: 
35 Figure 1 is a block diagram of a network manager an 

associated element managers and local exchanges, the networ 
manager including a computer system embodying this invention 
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Figure 2 is a biocJc diagram of the main sottware 
components of the network manager of Figure 1; 

rigure 3 is a block diagram showing the individual 
n^odules which form the transaction processing component of 
the network manager -of Figure 1 together with its 
relationship to the other software components; 

each of Figures 4 to 6 is a flow chart illustrating 
the operation of one of the modules of the t r a n s a c t i o n 
processing component; 

Figure 7 is a block diagram of set of computers which 
together form a computer system having a client-server 

architecture; and 

Figure 8 is a block diagram of the hardware components 

of the network manager shown m Figure 1. 

Referring now to Figure 1, there are shown three local 
exchanges 10, 12, 14 which form part of a public 
telecommunications network. Although not shown in Figure 1, 
the local exchanges are connected to trunk exchanges and the ■ 
trunk exchanges are all fully interconnected to each other. 
The local exchanges 10, 12, M are managed, respectively, by 
element managers 16, 18, 20. The three element managers 16, 
18 20 are managed by a network manager 22. Although not 
Shown m Figure 1, each of the remaining exchanges of the 
network is managed by a respective individual element 
25 manager. The element managers are managed by further 

network managers, not shown. 

Because of the complexity of an exchange, each 
exchange is provided with an individual element manager. By 
way of modification, the exchanges may be managed directly by 
30 the network manager 22 without the intermediate use of 
element managers. Element managers are also, provided for the 
other elements of the network, such as multiplexers, and each 
of these element managers manages typically many individual 
elements. These further element managers are managed by one 
35 or more further network managers, not shown. 

The network manager 22 sends instructions to the 
element managers for configuring the exchanges managed by 
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them. The instructions sent to each element manager can 
include instructions to connect or disconnect customers from 
the local exchange as well as instructions for handling calls 
by that exchange. The element managers also receive data 
5 from the exchanges which they manage regarding their 
operating state and pass this data to the network manager 22. 
The network manager 22 has a database in which is stored data 
relating to the state of the exchanges. 

The general arrangement of network manager 22, element 

10 managers and exchanges managed by the element managers as 
described above with reference to Figure 1 is well known tc 
those skilled m the art. By way of example, the local 
exchanges 10, 12, l'4.may be System X exchanges manufactured 
by GEC Plessey Telecommunications pic. The network managei 

1 5 22 is implemented as a computer. The main hardware components 
of the computer which implements the network manager 22 are 
shown in Figure 8. These comprise storage 60, a central 
processing unit (CPU) 62, a visual display unit (VDU) 64, £ 
keyboard 66 and input/output ports 68. The storage 6C 

20 comprises hard disc memory, random-access -memory (RAM) anc 
read-only-memory (ROM). The software which controls the 
computer is stored m storage 60. The software includes c 
client-server architecture embodying this invention. Tht 
software of the network manager 22 will now be described ir 

25 more detail with special reference to the client-server 
architecture. 

Referring now to Figure 2, there are shown the mai: 
software components of the network manager 22. Thes« 
comprise a set of application programs 30, a user interfac* 
30 32, a transaction processing component 34, a database 36 an; 
a communications stack 38. Although not shown, th 
components also include the operating system for the compute 
which implements the network manager 22. 

The application programs 30 are the programs which ar 
55 responsible for sending instructions to the element manager 
and receiving data from them. The construction of sue 
programs for a network manager is generally well known t 
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those skilled in the art. The user interface 32 is the 
software component which permits the user to access the 
network manager and the construction of user interfaces is 
also generally well known to those skilled in the art. 

The database 36 is the database mentioned above which 
contains data relating to the operational state of the 
exchanges. By way of example, the database 36 may be the 
well known ORACLE database management system. The 
communications stack 38 is responsible for converting both 
outgoing and incoming messages between the .form used by the 
network • manager 22 and the form which is suitable for 
transmission along the communication links which connect the 
network manager 22 and the various element managers. The 
construction of communications stacks is generally well known 
to those in the art and it is now usual for a ccmmuni cations 
stack to be provided as a standard component of the operating 

system of a computer. 

The application programs 30 generate requests for both 
the database 36 and the communications stack 38 to perform 
jobs. in the case of the database 36, the jobs take the form 
of either requests to enter data into the database 36 or to 
retrieve data from it. In the case of the communications 
stack 38, the Dobs take the form of requests- to send r^.essa^es 
to the element managers. The transaction processing 
>5 component 34 is responsible for scheduling the Dobs and this 
component will now be described m more detail with reference 
to Figure 3- 

Referring now to Figure 3, there are shown the 
individual software modules which form the transaction 
30 processing component 34 together with the relationship of 
these modules to the other software components of the network 
manager 22. These other components comprise the user 
interface 32, the database 36, the communications stack 38 
and a set of client modules 50. In Figure 3, for reasons of 
simplicity, there are shown only three client modules 50 but. 
in practice, there would be a much larger number of these 
modules. in the present example, each of the client modules 
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50 is one of the application programs 30. By way of 
modification, the client modules could form part of the 
transaction processing component 34 and serve the function of 
interfacing to the individual application programs. 
5 The transaction processing component 34 comprises 

software modules JBM, SMAN, REG, TARGET, ADB and TCM. k£ 
shown in Figure 3, the transaction processing component 34 
also has two servers 52 for accessing the database 36 and two 
servers 54 for accessing the communications stack 38. Thus, 

10 the servers 52 provide an interface to the database 36 and 
the servers 54 provide an interface to the communications 
stack 38. Thus, a request to run a j ob on one of the servers 
52 also represents a request to run the job on the database 
36. The communications stack 38 is part of an interface to 

IS the element managers 16, 18, 20 and, as will be recalled, 
these element managers manage the local exchanges 10, 12, 14. 
Thus, a request to run a job on one of the servers 54 
represents, ultimately, a request to run the ] ob on one of 
the local exchanges. Thus, database 36 and the local 

20 exchanges 10, 12, 14 represent resources accessed by the 
servers. The servers 52 belong to a first type of server and 
the servers 54 belong to a second type of server. For 
reasons of simplicity, only two servers ar« shown of each 
type but, in practice, there will be more than two servers of 

25 each type. 

The general function of each of the software modules 
which form the transaction process in component 34 will no^ 
be outlined and this will be followed by a detailed 
description of each of these modules. 

30 The module JBM is responsible for the management o: 

each request received from one of the clients 50. The moduli 
JBM checks each request to see if the job can be execute^ 
immediately. If it cannot be executed immediately, it i. 
placed on a queue. If a job can be executed immediately, i 

35 IS passed to the module SMAN which loads it on to a server 
The module REG keeps a list of clients which have registere 
with the transaction processing component 34 and from whic 
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requests can be accepted. The module TARGET keeps account of 
the number of jobs running on each of the resources accessed 
by the servers 52, 54. The module ADB maintains details of 
each executed job. The module TCM provides the user with 
5 access to the modules JBM, REG, TARGET and ADB 

In more detail, the module JBM receives the requests 
to run jobs from the servers 50. The steps for processing 
each job request in the module JBM will now be described with 
reference to Figure 4. 
IQ On receiving a request to run a job from a client, in 

a step SIO a check is made with the module REG to determine 
if the client is registered with the transaction processing 
component 34. The purpose of this step is to prevent jobs 
being run which are received by accident from clients which 
15 are not registered. If the client is not registered, 
processing of the 30b is terminated. If the client is 
registered, in a step Sll, a check is made with the module 
TARGET to determine if the resource for which the Dob is 
destined is free. If the resource is not free, in a step 
20 S12, the job is placed on a queue (the holding queue) of jobs 
which are waiting for a resource to become free. 

Some jobs are scheduled for execution at a later time. 
If it is found in step SI I that the resource is free, in a 
step S12 a check is made to determine if the job is scheduled 
25 for execution at a later time. If the job is scheduled for 
execution at a later time, in a step S13 it is placed on a 
queue (the queue of scheduled ]obs) for jobs which are 
scheduled for execution at a later time. 

If in step S12 it is found that the job is ready for 
20 immediate execution, in a step S13 a check is made with the 
module SKAN to determine if a server is free to run the job. 
For each of the two types of server, the module JBM has a 
queue (a ready queue) of jobs which are waiting for a server 
to become free. If in step S13 it is found that a server is 
35 not free to run the ^ob, then in a step 514 the job is placed 
on an appropriate one of the two ready queues. If in step 
S13 it is found that a server is free to run the job, in 
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Step S15, the module JBM instructs the module SMAN to loat 
the job on to the server. 

As will be explained below with reference to th 
module SMAN, when a job has been run on a server, it i 
5 unloaded from the server by the module SMAN and this modul 
then informs the module JBM. The module JBM then de-queue 
a job from the appropriate ready queue in accordance with 
predefined criterion and instructs the module SMAN to load i 
on to the free server. The module SMAN has four predefine 
10 criteria for selecting the next job to be loaded onto a fre 
server. By using the module TCM, the user can select, fc 
each type of server, the particular predefined criterion t 
be used. These four predefined criteria will now I 
described- 

Xhe first predefined criterion is simply that the ne> 
job m the appropriate ready queue is selected as the ne> 
]ob to be loaded onto the free server. 

The second predefined criterion is that the next jc 
m the appropriate ready queue for the same resource as ti 
20 previous job is selected as the next job to be loaded ont 
the free server. Thus, if the previous job was destined f( 
local exchange 10, the module JBM selects the next job in t! 
appropriate ready queue for the local exchange 10 as the nex 
job to be loaded onto the free server. If there is no job i 
2 5 the appropriate ready queue for the same resource as tt 
previous job, the next ] ob in the ready queue is selected a 
the new job. 

The third criterion is that the next 30b of the sa 
type, regardless of the resource for which it is destined, 

30 the appropriate ready queue is selected as the next job to 
loaded onto the free server. Thus, if the previous job w 
to connect a new customer to a local exchange, the module J 
selects the next Dob for connecting a new customer to a loc 
exchange as the next job to be loaded onto the free serve 

35 If there is no job in the ready queue of the same type as t 
previous job, the next job in the ready queue is selected 
the next 30b to be loaded onto the free server. 
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The fourth predefined criterion is that the next job 
in the appropriate ready queue of the same type and destined 
for the same resource as the previous job is selected as the 
next job to be loaded onto the free server. If there is no 
5 job in the ready queue of the same type and destined for the 
same resource as the previous job, then the next job which is 
destined for the same resource as the previous :ob is 
selected as the next job to be loaded onto the free server. 
If there is no : ob in the ready queue destined for the same 
10 resource as the previous job, then the next 30b in the ready 
<5ueue is selected as the next job to be loaded onto the free 



server. 



In the queue of scheduled jobs, the jobs are arranged 
in order by their scheduled times of execution. For the job 
15 which is scheduled to be executed next, a timer . is 
established. At the time at which the ]ob should be 
scheduled, further processing of the. job commences at step 
S13. 

As will also be explained below, when a resource 
20 becomes free, the module TARGET informs the module JBM. The 
module JBM then removes the next job from the holding queue 
which is destined for the resource which has become free and 
processing of this job recommences with step S12. 

The module JBM receives requests to run two types of 
25 jobs. in the first type of jobs (attached jobs), the client 
and server are connected together while the 30b is being run 
on the server. In the second type of jobs (detached :obs), 
the client and server are not connected while the job is run. 
Detached jobs have the advantage that they can be run without 
30 occupying the client. When the module JBM receives a request 
to run a detached job, the details of the DOb are stored and. 
then retrieved when the 30b is unloaded from a server. 

Referring now to Figure 5, there are shown the steps 
which are performed by the module SHAN on receiving a request 
35 from the module JBM to load a job on to a server. After 
■ receiving' a request to load a job on to a server, in a step 
S20 the module SMAN loads the job on to a free server. 
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Then, in a step S21, it waits for notification from the 
server that the job has been completed. When it receives 
notification that the job has been completed, in a step S22, 
It unloads a job from the server. In the case of an attached 
5 job, the job is unloaded by breaking the connection betweer 
the' client and the server. In the case of a detached job, 
the job is unloaded by transmitting the results of the job tc 
the client from which the request came. Then, in a step S23, 
the module SMAN notifies the module JBM that the lob has beei 
10 completed and that the server has become free. In a ste] 
S24, the module SMAN notifies the module TARGET that the ^o! 
has' been completed. The module TARGET uses this data to kee; 
count of the number of jobs which are being run on th 
relevant resource. Finally, in a step S25, the module SKA 
l-^ notifies the module ADB that the :ob has been cor.plet* 
'together with the derails of the job. The module ADE use 
this data to provide a log of completed jobs. 

The module SMAN is also arranged to create and delet 
servers. For each type of server, the module SMAN maintain 
20 a table of the existing servers of that type together with 
table containing the number jobs waiting in the ready queu 
for execution on that type of server. The module SMAN i 
arranaed to maintain the number of servers of each type at a 
optimum level for the number of DObs which are awaitin 
25 execution. The procedure for achieving this for each read 
aueue in shown in Figure 6. In a step S30, the number c 
jobs on the ready queue is compared with the number . 
servers for serving Dobs on that queue. Using a criteri. 
pre-set by the user, the comparison is used to establish 
30 servers should be created or deleted so as to achieve t 
optimum number of servers. For example, the criterion cou 
be that the ratio of the number of jobs in the ready queue 
the number of servers should be kept at a certain valu 
Then, in a step S3 1, servers are created or deleted 

3 5 appropriate. 

As will be explained below, the user is able 
instruct the module SMAN to create and delete servers. 
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The module REG maintains a list of clients which are 
registered with the transaction processing component 34. By 
using the module TCM, the user can add and delete clients and 
inspect the list. As explained above, the list of clients is 
5 accessed by the module JBM each time it receives a request to 
run a job from one of the clients. 

For any resource, the number of jobs which can be run 
at any one time efficiently is limited. The database 36 is 
able to handle a relatively large number of jobs 

10 simultaneously. In contrast, as the main function of the 
local exchanges 12, 12, 14 is to process telecommunication 
calls, the amount of computing capacity to run jobs requested 
by the network manager 22 is limited and only a few of such 
3obs can be run simultaneously. 

15 The function of the module TARGET is to keep a count 

of the number of jobs which are running on each resource and 
also to maintain a threshold value for the maximum nuT.ber of 
jobs which can be run on each resource. For each resource 
the module TARGET maintains a list of jobs which are running 

20 on it. When the module SMAN unloads a job from a server, it 
notifies the module TARGET which then deletes the job from 
the list for the appropriate resource. As explained above, 
when the module JBM receives a request to run a new ] ob, it 
checks with the module TARGET if the resource is free to run 

25 the job. The module TARGET then compares the number of jobs 
running on that resource with its threshold value and thus 
determines if the resource is free to accept a new job. If 
the resource is free to accept a new job, the module TARGET 
adds the job to the list for that resource and informs the 

30 module JBM that the resource can accept a new job. If the 
resource is not free to accept a new job, the module TARGET 
informs the module JBM of this. 

By using the module TCM, the user can change the 
threshold value for each resource and also obtain a list of 

3 5 jobs presently running on each resource. 

The module ADB maintains a database containing details 
of completed jobs. Each time a job is unloaded from a server 
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the module SMAN sends details of the completed 30b to th€ 
module ADB and the module ADB stores these details m its 
database. The module ADB also maintains files containim 
details of jobs. At the end of each day, details of the jobi 
5 are transferred from the database to the files following 
selection procedure established by the user. Thus, th- 
database requires only limited amount of data storag 
capacity. By using the module TCM, the user can inspect th 
data in the database and m the files. Thus, the module AD 
10 enables the user to monitor the performance of th 
transaction processing component 34. 

The module TCM provides the user with access to th 
modules JBM, REG, TARGET and ADB. In the case of the modul 
JBM, It permits the user to inspect the jobs on each queue 
15 to delete 3 obs from queues and to change the scheduled time 
of execution for 3 obs on the queue of scheduled jobs. ,In th 
case of the module REG, it permits the user to add and deiet 
clients from the list cf registered client. In the case c 
the module TARGET, it permits the user to inspect the jor 
20 running on each resource and also to change the threshol 
value for the maximum number of jobs which can be run on eac 
resource. In the case of the module ADB, it permits the us? 
to inspect details of the 3 obs stored on both the databat 
and the files and also to change the selection procedure fc 
25 transferring details of jobs from the database to the files 
Although the transaction processing component 34 ha 
been described with reference to a network manager, it can ^ 
used in any computer system which has a client-serv 
architecture. Figure 7 shows a set of computers 50. 51, 
30 and 53 which are connected together by a telecommunicatio 
network 54. As indicated by the dotted line, the number 
computers connected in this way can be greater. Both clien 
and servers can be provided m any of the computers 50 to 5 
thereby providing the client-server architecture. In ore 
25 to control the scheduling of requests to run jobs between t 
clients and servers, one of the computers, for example t 
computer 50, is provided with a transaction process: 
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component generally similar to the transaction processing 
component 34 except that it does not include servers. 
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CLAIMS 

1. A computer system having a client-server architecture, 
said system comprising: 

5 a set of clients; 

a set of servers for serving requests from the clientt 
to run jobs; 

means for managing requests from the clients to ru: 
:jobs on the servers; and 
10 means for loading jobs on to the servers; 

said request managing means being arranged to receiv 
requests from the clients and, on receiving a request, t 
perform the following operations: 

check if a server is free to run the job; 
15 if a server is net free, put the lob on a queue fo 

jObs each of which is ready for execution when a serve 
becomes free; and 

when a server is free to run a job, instructing sai 
30b loading means to load a job on to that server. 

2C 

2. A computer system as claimed in claim 1, m which, th 
request managing means is arranged to select the next ]ob t 
be loaded onto a free server in accordance with a pr€defin«. 
criterion. 

25 

3. A computer system as claimed in claim 1 or claim 2, i: 
which, on receiving a request to run a job, said reques 
managing means is arranged to perform the additlonc 
f oil owing operations : 

30 check if the job is scheduled for execution at a tir 

m the future; and 

if the job is scheduled for execution at a time in t: 
future, put a ]0b on a queue for jobs each of which 
scheduled for execution at some time in the future. 

3 5 

4. A computer system as claimed in any one of t 
preceding claims, m which, on receiving a request to run 
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job which is destined for a resource accessed by a server, 
said request managing means is arranged to perform the 
following additional operations: 

check if the resource is free to run the job; and 
5 if the resource is not free, put the job on a queue 

for jobs each of which is waiting for a resource to become 
free. 

5. A computer system as claimed in claim 4, including a 
10 database for maintaining data on jobs running on the or each 

resource which is accessed by a server, for the or each 
resource said database keeping a count of the number of jobs 
being run on the resource and a threshold value for the 
number of jobs which can be run on that resource. 

I 5 

6. A computer system as claimed in claim 5, in which, 
said request managing means accesses said database in order 
to check if a resource is free to run on a 30b. 

20 7. A computer system as claimed in claim 5 or claim 6, 

including means for permitting a user of the computer system 
to set the threshold value for the or each resource. 

8. A computer system as claimed in any one of the 
25 preceding claims, further including means for creating and 

deleting servers, said server creating and deleting means 
being arranged to compare the number of jobs on the queue of 
jobs ready for execution with the number of servers for 
serving the Dobs, and to create or delete servers in 
30 accordance with the result of the comparison. 

9. A computer system having a client-server architecture, 
said computer system comprising: 

a set of clients; 
35 a set of servers for serving requests from the clients 

to run jobs; 
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means for managing requests from clients to run :obs 

in servers; and 

means for loading jobs on to servers; said request 

managing means being arranged to receive requests from the 
5 clients and, on receiving a request from a client to run t 

job which is destined for a resource accessed by a server, t< 

perform the following operations; 

check is the resource is free to run the job; and 
if the resource is not free, put the job on a queu. 
10 for jobs each of which is waiting for a resource to becom. 

free. 

10. A network manager for managing at least one element o 
a telecommunications network, said network manager includin 

15 a computer system as claimed in any one of the precedir. 
claims. 

11. A method of operating a computer system having 
client-server architecture, said computer system comprisir 
a set of clients and a set of servers for serving request 
from the clients to run jobs, for each request made by 
client to run a 30b on a server, said method comprising ti 
steps of: 

checking if a server is free to run the job; and 
if a server is not free to run the job, putting th 
job on a* queue for jobs each of which is ready for executic 
when a server becomes and 

when a server is free to run the job, loading a :ob 

to the server. 



20 



25 



30 



12. A method of operating a computer system as claimed 
claim 11, in which the method includes the step of selecti 
the next job to be loaded onto a free server in accordar 
with a predefined criterion. 



35 
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13. A method of operating a computer system as claimed in 
claim 11 or claim 12 in which, for each request to run a job 
on a server, said method including the additional steps of: 

checking if the job is scheduled for execution at a 
5 time in the future; and 

if the job is scheduled for execution at a time in the 
future, putting the job on a queue for jobs each of which is 
scheduled for execution at a time in the future. 

10 14. A method of operating a computer system as claimed in 
claim 11, claim 12 or claim 13 in which, for each request to 
run a job which is destined for a resource accessed by a 
server, the method includes the following additional steps: 
checking if the resource is free to run the job; and 

15 if the resource is not free, putting the .job on a 

queue for jobs each of which is waiting for a resource to 
become free. 

15. A method of operating a computer system having a 
20 client-server architecture, said computer system having a set 
of clients and a set of servers for serving requests from the 
clients to run jobs, for each request made by a client to run 
a job on a resource accessed by a server, said metiiod 
including the steps of: 
25 checking if the resource is free to run the job; and 

if the resource is not free, putting the job on a queue for 
3 obs each of which is waiting for a resource to become free. 



wo 96/03<92 



PCT/CB95/0n05 



1/6 



Fig.1. 

22 



NETWORK 
MANAGER 



ELEMENT 
MANAGER 



16 



ELEMENT 
MANAGER 



18 



ELEMENT 
MANAGER 



20 



10 



LOCAL 
EXCHANGE 



LOCAL 
EXCHANGE 



12 



14 



LOCAL 
EXCHANGE 



Fig.2. 



30 



APPLICATION 


USER 


PROGRAMS 


INTERFACE 


TRANSACTION 


PROCESSING 


DATABASE 


COMMUNICATIONS 


STACK 



36' 



38 



32 



34 



SUBSTITUTE SHEET {RULE 26) 



wo M/0369: 



PCT/CB95/0I705 



2/6 




52 



SERVER 



L 



•52 



SERVER 



DATABASE 



36 




6NSOOC10 *WO 96036fl2Al> 



SUBSTITUTE SHEET (RULE 26) 



wo 96/03692 PCT/CB95/01705 



3/6 





NO 







PUT JOB ON 
READY QUEUE 






SUBSTITUTE SHEET (RULE 26j 



wo 96/03<92 



PCT/CB95/01705 



4/6 

Fig. 5. 

( SMAN ) 



LOAD JC 
SEP 


)B ONTO 
VER 






WAIT FOR JOB 
TO FINISH 






UNLOAD JOB 
FROM SERVER 






NOTIFY JBM 






NOTIFY 


TARGET 






NOTIFY ADM 



S20 



S21 



S22 



S23 



S24 



S25 



Fig.6 

( SMAN ) 











COMPARE NUMBER OF 

JOBS ON READY 
OUEUE WITH NUMBER 
OF SERVERS 








CREATE OR DELETE 
SERVERS 


t 



S30 



S31 



ar«0OCID <WO 9«0369aAl> 



SUBSTITUTE SHEET (RULE 261 



wo 96/03692 PCT/GB95/ono? 



5/6 



Fig.7. 



50 

COMPUTER 



54 







COMPUTER 







53 



8NSOOC1D tfWC 06a36nA1> 



SULSTiTUTE SHEET (RUL£ 26> 



wo 96/03692 



PCT/GB95/OI705 



6/6 





D 
G 
> 



BNSOOCtO <WO 96036«A1> 



SUBSTITUTE SHSH (r.ULE 26) 



INTERNATIONAJ. SEARCH REPORT 



PCT/GB 95/01705 



A. CUkSSIFICATION OF SUBJECT MATTER 

IPC 6 G06F9/46 



AccDT^ni to tn»TTUDO»ul PlCTt Q>JM6«oon (IPO or » boft ruoowai df ficaowi »nd rPC 



B. FTELOS SEARCHED 



MLmnum aoeummunon scvdicd (d4«&c*oon lyaem Wto*«4 fty duBfiMaon fymooii) 
IPC 6 G06F 



DooncBU&n lurtbal otter 0U0 nanuun AonascBUsan to ttc cxwii ttut ~cn ooctftieoa an 



•rr*''^**^ la om &ddi MArdMd 



C. DCXI^MENTS CONSrPERED TO BE RELEVANT 



CUatory ' Quo« or boc«ncm, mAcaaoo. wtwt tp^^uc. of tec rtlcwi ptMfa 



Rctevnt to dAUB No. 



us. A, 5 249 290 (HEIZER) 28 September 1993 
see the whole document 

US. A, 5 325 527 (CWIKOWSKI ET AL.) 28 June 
1994 

see the whole document 

EP.A.O 601 579 (MITSUBISHI) 15 June 1994 
see the whole document 

EP.A.O 384 339 (DIGITAL) 29 August 1990 

see abstract 

see column 1 - column 4 

see column 12, line 13 - column 15. line 

11; figures 1-7 

see claims 1-28 



1-15 

1-4,9-15 
5-8 

1-15 

1-15 



Funher 



t lifud ID QIC eooBBUAaon of box C. 



0 



SpeaAi uttfono of atcd thw uimw : 

A' (tocwMni dcfinmi ft« fcnermt luu of toe an wtecb is not 

ooem^nd to be of panaitr rctcvancc 
'E' eartiff aoeaunaii but pUhQ<»«rt on or tAc OK tru«*oon*l 

fUini OAU 

'L' doc«nent *i^nc*i m»y ttro» rtoubB « ptiomydAitrti) or 
«tacA 11 aua to ouBluh ttM puttieaaon dAU of aaoeicr 
aCASon or oOter fpeoAl kmoo <ai ^cafictf) 

•Q' bocwneni pefffnni to An otaI dudOMt. utt, c^btoon or 
oetc mCAAJ 

'P* docwaent pubUAcd fjnor to 1M uHcmASonAl rumg tfAU tet 
Uu7 lAAn the pnonty Oau clAioicd 



T lAter Ooeumoit publttfwd aAct ih< Attm«aanAl ftliftg Iau 
or monty dAtc at^ bot in oonAiet vitA Ox a^^caoob but 
oted to vnAcnuad ft( pnaopic or theory tndslywf Stc 
lawttoe 

*X' tectfitBtt of pAracdAT rdcvsDcc; the dAUDcd invrooo 
cAMOt be ootwdercd ne«d or cAnnot be eonabotd » 
involve a lavcBSvi «ep «btt tbc ooctnoii is uJtca Aim 

*Y' doanni of pmaAjr RtevvMc; ttw dAuncd tiroaon 
CAODOt be eoflBdovd to un«ivc ah invtnovt ocp wtus me 
oooment it eomtuKd wim ooc or oiore wdi docu- 
RKin, bicb oomttMAon boni obvious lo a poiob ttUlcd 
m tbc An. 

'A' doanatskoiteof mettmcpAtatfAfflily 



Dau of mc A£XUAi coen^c&oo of oc intmkAOonAi icArcti 



18 October 1995 



Diu of muuai of the intaBMOBil tMith rtpon 



1 0. 11 95 



NAffic And tDAiimf A*»i of the ISA 

Euffvpnn pAicDt OfTioe. P.B. Stl S PAtctAAAn 3 
NL - 2210 HV Kiwwiik 
Td ( * VW-atMO, Tx. 11 631 «po rU, 

Fas ( •* 31-70) >4O-301fr 



Auiaoruea ofliccr 



page 1 of 2 



INTERNATlONAi. SEARCH REPORT 



C^Cananutton) DOCUMEKH CONSIDEIUD TO BE RELEVANT 



iMcn^ : KptAKMoa So 

PCT/GB 95/01705 



Quaoo of c 



lUlrrvai to ovm no. 



MICROPROCESSING AND MICROPROGRAMMING, 
vol. 12, no. 3/4. October 1983 , 
AMSTERDAM, NL, 
pages 159-166, 

A. CORRADI ET AL.: 'Using the iAPX-432 
System is a Support for Chill Parallel 
Constructs' 

see page 160, left column, line 9 - page 
161. left column, line 22 

HEWLETT-PACKARD JOURNAL, 

vol. 41, no. 2, April 1990 , US, 

pages 54-59, 

K.S. KLEMBA ET AL.: 'HP OpenView Network 
Management Architecture' 
see figures 1,4 



I, 2,4,9. 

II, 15 



10 



) Umtf IfO) 



page 2 of 2 



f 



INTERNATIONAL SEARCH REPORT 



invnw ApiAicMoc No 

PCT/GB 95/01705 



Pueni documtnt 
sicd in mrdi rtpcrt 



Publauon 



Ptuni fainily 



Publcauon 



US-A-5249290 



US-A-5325527 
EP-A-0601579 



EP-A-0384339 



28-09-93 
28-06-94 
15-06-94 



29-08-90 



NONE 
JP-A- 



6301619 



JP-A- 
GB-A- 



6282S16 
2273378 



AU-B- 
AU-B- 
AU-B- 
AU-B- 
CA-A- 
JP-A- 
US-A- 



611605 
4996190 

630291 
7603391 
2010762 
3116262 
5341477 



28-10-94 



07-10-94 
15-06-94 



13-06-91 
13-09-90 

22- 10-92 
15-08-91 
24-08-90 
17-05-91 

23- 08-94 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SffiES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 



U'REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 
□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




